Using DocBook to Produce a Polyvalent Academic Work

Creatingmany different versions or customizations by configuring a collection of components is a desirable goal in many domains. A single automobile production line can support the assembly of customized variations of a car model. Software product line engineering enables the creation of many similar software systems from a shared set of software assets. In this article we discuss how a collection of content elements can create a family of related texts whose different members are generated according to configurations of variables found in the content markup. This markup is created by the author, but anyone can create a particular edition of the text by defining a configuration file at book-building time, and a reader can do this interactively at reading-time bymaking selections from a configuration control widget. We call this configurable collection of content elements a "polyvalent" document: "Poly" means "more than one" or "many" "valent" means "having combining power." There are some common challenges in all of these domains. The first is to distinguish the components that are contained in everymanifestation, typically called the core, base, or platform, from those that vary, typically called the features, options, or supplements. The second is to organize the variable components to indicate the different customizations, versions, or editions that can be built by selectively combining optional components with the required ones. The third challenge is to convey to the builders, users, or others who want to use the variable components any dependencies or constraints that might exist, since not every possible combination will be feasible or sensible. In this paper, we examine the facility with which DocBook was coerced into supporting a polyvalent text, and the challenges encountered.We observe the parallels and disjunctions among the vocabularies used in book production, the suitability of XHTML and CSS as content delivery agents, the varying